6.2 FHIR本地化定义
6.2.1 FHIR本地化资源
- ImplementationGuide（实施指南），实现指南定义了在一个特定场景下的FHIR资源、API、术语等的约束和扩展，是一个集合，满足一个特定的应用场景，比如互联互通。
- CapabilityStatement（能力声明），能力声明描述了一个系统支持的FHIR的能力，包括支持哪些API、资源定义、哪些操作（Operation）、哪些查询参数等
- 使用OperationDefinition来定义额外的操作
- 使用SearchParameter来定义额外的查询参数
- 使用StructureDefinition来约束一个资源的使用，或定义扩展，数据类型等
- 使用ElementDefinition来定义一个元素
- 使用ValueSet来绑定一个术语集
- 使用ConcepMap来定义术语之间的映射
区别于其他的本地化定义，HL7 FHIR使用资源的形式来定义本地化最重要的目标是方便实现，这些本地化资源和其他医疗领域资源一样是计算机可识别的，开发者可以开发特定的工具解析这些资源并自动生成相应的代码，从而快速的实现一个本地化的FHIR。
6.2.2 资源本地化定义
资源的本地化是通过StructureDefinition（结构定义）和ElementDefinition（元素定义）来实现的，一个资源的本地化在FHIR中称之为Profile，包括：Cardinality（重复性）、元素的数据类型约束、术语与值集绑定、Slicing以及扩展的定义与应用，结构定义如下图所示：
所有的针对元素的使用约束都是通过Snapshot或Differential中的ElementDefinition来定义的，其中Snapshot定义了一个资源中完整的元素列表，而Differential则定了那些和标准资源不一样的元素。元素定义如下图所示：
6.2.2.1 Cardinality（基数）约束
元素的基数是由Element Definition中min和max两个属性来定义的，可以通过设置max=0来删除一个元素（min也为0），也可以设置min=1来约束该元素必须出现，元素的基数定义可参见4.9.3.3中相关定义。
在该规则之外的约束都是非法的，例如，如果标准中定义的一个元素的Cardinality是1..n，那么该元素是不能约束为0..1或0..n，Cardinality的约束基本原则是越来越严格，而不是宽松。
6.2.2.2 元素的数据类型约束
在FHIR基础标准中，我们经常会在资源中发现一些元素的数据类型有多个选项，之所以出现这种情况是FHIR为了满足不同地域、应用场景而设计的，而当我们在一个特定的区域或场景时，就需要对选择的数据类型做进一步的约束，比如Observation.subject的数据类型是一个Reference，标准中定义可以引用到Patient、Device、Group和Location，而在实际应用中，我们可以只会引用到Patient，那么在这种情况下，就可以通过type这个属性进行约束，如下图所示。
6.2.2.3 元素的术语绑定
当一个元素的数据类型为code、Coding或CodableConcept时，需要引用其对应的术语或值域，既可以引用到一个ValueSet资源，也可以引用到一个外部的术语系统定义的字典，术语或值域的引用有不同的强度要求：
在进行术语或值集绑定时，需要满足下列的规则：
和Cardinality一样，术语绑定的强度的基本原则是越来越严格，而不是越来越松。术语的绑定时通过binding这个属性来定义的，在binding中，通过strength来指定该元素绑定值集的强度，而通过valueSet来指定相应的值集。
6.2.2.4 Slicing
为了满足不同地域或场景的需求，FHIR在定义的时候把很多的元素的cardinality都定义成了0..*，这样的定义会给实际的实现带来挑战，比如在Patient资源中的identifier，在实际的应用中我们希望能够约定一些特定的身份信息如：身份证号，医保号等必须包含，面对这样的需求，FHIR是通过slicing来实现的，其核心的理念就是将资源中出现多次的元素拆分成多个单个且不同值的元素，每一个元素只包含一个固定的值，这个过程称之为“Slicing”，Slicing是用来定义Profile的，但并不会改变Resource实例的结构。我们再举高血压为例，高血压在FHIR中用Observation来定义，在基础的Observation中包含了一个0..*的component，在高血压这个例子中，我们需要约束必须且只包含两个component（收缩压和舒张压），如下图所示：
面对上述的需求，HL7 FHIR是通过ElementDefinition中的slicing属性来实现的，在高血压这个例子中，我们可以定义两个元素，通过slicing约约定一个component是收缩压，另外一个component是舒张压，如下图所示：
我们不难发现两个component的路径是一样的，那么如何进行区分呢，它是通过slicing.discriminator来进行区分的，如下图所示，可以在discriminator中指定使用那个路径的元素来进行区分，在高血压中使用了code.coding.code这个元素来进行区分。
此时，通过指定的fixedCode为固定值来约束该component是舒张压或收缩压。如下图所示：
6.2.3 交互本地化定义
FHIR作为接口规范，它指定了医疗健康信息应用程序之间交换的数据内容，以及交换的实现方式。FHIR定义了5种在系统之间交换数据的交换框架（exchange framework）：RESTful API、消息交互（Messaging）、文档交换（Documents）、面向服务架构的SOA交换（Services）及数据库/永久存储（Database/Persistent Storage）。这些方法中的每一种都可用于交换信息，每种方法都有自己的优点和缺点以及适用范围。FHIR对系统使用数据交换方法无任何限制，根据实际应用场景和技术背景，选择一种或多种交互方式进行数据共享及互操作。
6.2.3.1 RESTful API
REST是目前较流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、扩展方便，所以被越来越广泛的使用。FHIR被描述为“RESTful”规范，其核心主要包含两个主要组成部分：资源和API。REST是最简单的一种交互机制，基于HTTP实现。FHIR规范定义的客户端/服务器RESTful API的设计遵循RESTful 设计原则和约束条件，支持对资源的创建（Create）、读取（Read）、更新（Update）和删除（Delete）等常见操作，即CRUD，也支持简单或复杂的查询（Search）和操作（Operation）。
FHIR目前定义了三个层次的交互，如下表所示。
表1 REST API接口定义
| 实例层面的交互 | read | 读取资源实例的特定版本状态 |
| vread | 读取资源实例的特定版本状态 | |
| update | 使用id更新已经存在的资源实例 | |
| path | 通过一组变化的值来更新已存在的资源实例 | |
| delete | 删除资源实例 | |
| 类型层面的交互 | create | 用服务器指定的id创建新资源类型 |
| search | 基于筛选条件查询资源类型 | |
| history | 获取特定资源类型的修改历史记录 | |
| 整个系统的交互 | capabilities | 获取系统的能力声明 |
| batch/transaction | 在单一交互中更新、创建或删除一系列资源实例 | |
| history | 获取所有资源的修改历史记录 | |
| search | 基于筛选条件，在所有资源类型的范围内进行查询 |
FHIR可通过定义RESTful API的方式进行资源数据的交互，其交互方式如下：
VERB [base]/[type]/[id] {?_format=[mime-type]}
- VERB是交互操作：根据HTTP标准，HTTP请求可以使用多种请求方法。在操作过程中的交互行为可以通过请求方式来区分。通过GET、PUT、POST、DELETE等请求方式体现资源操作过程中的增、删、改、查。
- base是服务器基础URL。对应资源所在系统主机的地址或域名，资源里面的数据由该主机使用的医疗系统在维护管理。
- type是标识当前操作的资源类型。
- id是资源唯一身份标识Id。
- {}中间的部分是各种可选的参数。
RESTful API是一个通用接口，可用于在系统间推送和拉取数据，其高度细粒度的对资源进行管理和交互。传输时可以仅传必要的信息，无需传完整的上下文。轻量级的交互效率比较高，适合于业务集成度更紧密的互操作场景，如：
- 系统间低耦合
- 轻量级交换。
- 聚焦于CRUD操作。
- 客户端驱动、客户端/服务器模式。
- 服务器端有固定地址。
- 适用于移动端、PHR等场景。
a) 查询及查询参数（SearchParameter）
查询操作是一个基础性的操作。在FHIR中，可以通过筛选一系列参数进行查询操作。查询操作可以是简单的也可以是复杂的，搜索在RESTful框架中执行GET或POST动作来完成：
GET [base]/[type]?name=value&...{&_format=[mime-type]}}
POST [base]/[type]/_search{?[parameters]{&_format=[mime-type]}}
FHIR规范中定义的查询参数有适用于所有资源的通用查询参数，也有每一类资源的专属查询参数。根据实际交互查询场景，可选择FHIR规范中已经定义查询参数进行查询，也可以通过_query自定义查询参数进行查询。如果服务器从客户端接收到他们无法识别的参数，或者可能接收到他们识别但不支持的参数。通常，服务器应该忽略未知或不支持的参数。
b) 操作及操作定义（OperationDefinition）
FHIR规范除了为每一类型的资源中定义了一组基本RESTful API接口，针对一些深层次复杂操作，还定义了Operation。当FHIR规范定义的Operation不满足实际使用场景时，可以依据FHIR规范原则中的OperationDefinition资源自定义相应的Operation，内容包括：
- 操作的上下文：操作系统、资源类型或资源实例
- 操作的名称
- 参数列表及其定义
在FHIR中，每个资源以及该资源对应的RESTful API接口、Operation操作接口和查询参数都需在交互规范中明确声明，分别形成服务器端和客户端的CapabilityStatement交互能力声明文件。
6.2.3.2 消息交换：Messaging
消息交互是医疗信息互操作常见的方式之一。在FHIR消息交换中，当现实医疗场景的事件发生时，从源应用程序向目标应用程序发送请求消息。请求消息是由一个由“message”类型标识的资源束（Bundle）组成，资源束的第一个资源是MessageHeader资源。MessageHeader资源包括消息id、消息代码、消息事件、消息源等数据。资源束中的其他资源取决于请求的类型。FHIR规范假定消息内容通过某种传输机制从一个应用程序到另一个应用程序，然后一个或多个响应结果返回给源应用程序。具体的传输机制不在FHIR规范中定义，可以使用文件传输、基于HTTP的传输、MLLP、MQ消息等传输机制。
每一个FHIR请求消息都要有一个或多个响应消息，（MessageDefinition.responseRequired里支持不响应never）FHIR规范既支持同步消息交互模式也支持异步消息交互模式。
基于消息交互框架，FHIR针对MessageHeader定义了一个RESTful API接口——$process-Message。此操作目标系统接收消息，根据消息头中定义的事件对其进行处理，并返回一个或多个响应消息。有关详细信息，请参阅操FHIR官网描述。
作为发送方的应用程序需要在发布的CapabilityStatement中声明其支持的“FHIR消息”（FHIR messaging）。CapabilityStatement声明中包含消息的传输协议、MessageDefination概要文件的URL、以及关于单个资源信息内容的规则等。
消息交换的本质是一个中心化的互操作方式，适用场景如下：
1.请求/响应工作流程。
2.需要在单个资源上驱动比CRUD更复杂的查询。
3.需要异步通信、跨平台通信。
4.需要传达多个资源的信息，但希望尽量减少交换。
6.2.3.3 文档交换：Document
FHIR规范定义了基于文档的交换框架。构建的文档可以是临床文档，如入院记录、病程记录、手术记录等，也可以是非临床文档，如实施指南、患者手册等。所有文档具有相同的结构：一个“document”类型的资源束Bundle封装，它的第一个资源是Composition资源，后面是一系列被Composition资源引用并用于描述文档具体内容的其他的资源。与CDA文档一样，FHIR文档也具有永久性、完整性、关联性、阅读性、可管理性等特性。FHIR文档可以在系统之间交换并在系统中保存存储和维护管理。
文档交换框架适用场景如下：
1.永久保存数据。
2.不涉及工作流。
3.数据跨越多资源数据
4.数据共享。
针对FHIR文档的生成，规范中定义了一个$document的REST操作。客户端向服务器提交一个Composition资源通过请求$document的操作即可生成完整的Bundle文档。对于已有的FHIR文档，支持查询、读取的RESTful API操作。关于文档的生成、获取、检索等应用在IHE规范里有详细描述。
应用程序需在CapabilityStatement声明支持的FHIR文档及相应Profile路径，并标记出此应用程序对该文档是生成提供还是消费使用。
6.2.3.4 面向服务架构的SOA交换：Services
RESTful API、Messaging、Documents等任一种方法都可以定义或封装成一种“服务（Service）”。服务交互通常是基于面向服务的体系架构（SOA）、通过服务总线来进行交互，应用在低业务集成度和跨数据管理的业务环境。服务的定义是基于规范的业务流程和交互角色的，国际上常见的有IHE集成交互规范。
FHIR服务通过调用公共接口并根据明确定义的服务协议交换信息进行通信。SOA 为组件如何交互、如何划分职责以及如何管理系统不同部分之间的工作流提供了指导，所有这些都在 FHIR 实施设置中具有潜在的实用性。考虑使用FHIR和SOA有潜在的好处，FHIR允许以开发商的方式实现易于实现和随时访问数据的有效负载。SOA在分布式系统实例中的事务完整性方面已经成熟，为松散耦合和解决复杂分布式系统的前提条件、异常处理和其他实现注意事项提供了框架。
SOA适用场景如下：
1.除CRUD以外的资源操作（如决策支持）。
2.工作流程比简单的请求/响应更复杂。
3.低业务集成
4.跨数据管理
目前，CapabilityStatement不支持基于SOA服务的交换方式，因此现阶段可不用声明，但是需要在实施指导规范（IG）中有相关描述。
6.2.3.5 持久性存储
利用FHIR定义的资源的另一种方法是将保持资源的原本结构将其本地存储在数据库或持久存储中，不同的应用程序或模块通过对资源的写入和读取实现FHIR数据的互操作。FHIR资源是为了交互设计的，而不是作为数据库存储格式，因此实现基于持久性存储的交互方式时，需考虑如何设计出完全符合目的且高效的数据存储模式。在技术选择上可以考虑支持JSON的SQL服务器，如MongoDB及其他如Hadoop、BigQuery等NoSQL服务器。支持持久性存储方式交互的应用系统或模块需要支持FHIR服务器和FHIR资源仓库，能够实现“即插即用”的模式。
6.2.4 本地化一致性资源
在本章的上述小节中提到，为了适应特定的应用场景，需要对FHIR规范提供的一组资源做进一步的本地化适应性配置，这组资源统称为一致性资源。虽然这些通过本地化的一致性资源可以单独来使用，但通常用于实施指南（Implemention Guide）及能力声明（CapabilityStatement）的上下文中更为常见。
实施指南的内容是用Implemention Guide资源来说明的，是由提供FHIR服务的机构、供应商发布的网站说明，描述了FHIR服务支持了哪些特定的用例，实施指南将一组一致性资源和叙述性的支持说明结合到文档中，供实施者使用。
能力声明的内容是使用CapabilityStatement资源来说明FHIR服务的客户端或服务端支持的资源及交互。它与实施指南的差异是，实施指南是描述针对应用场景所需要使用FHIR服务的方法说明，而能力声明是所有一致性资源的集合，描述的是应用场景所支持的FHIR标准本身。
6.2.4.1 实施指南（Implemention Guide）
实施指南是一组关于如何使用FHIR服务来解决特定问题的规则，这些规则形成了一个阐明了FHIR服务支持的能力以及用法的相关文档，通过 FHIR 实施指南发布器可以在HL7提供的Web上注册发布。
实施指南中的内容
实施指南的主要用途是供实施者阅读、理解在特定业务场景中如何使用FHIR。因此，在一个典型的实施指南中，通常由一组一致性资源及叙述说明来构成实施指南中的内容。按照使用功能来说，涵盖以下类型的内容，
资源：
- 规范配置文件（Profiles）和扩展（Extensions）：对实施指南所涵盖的资源内容模型定义。
- 值集（Value Set）和代码系统（codeSystem）：实施指南所支持的术语定义。
- 能力声明、操作定义以及检索参数：对如何使用FHIR API的定义。
- 测试用例：一组用于测试验证实施指南内容合规性的用例或脚本。
- ConceptMap和StructureMap：对FHIR代码系统和资源配置映射及转换的定义。
- 示例：进一步说明实施指南中的各类资源。
- 叙述性描述：
- 过程信息：实施指南的版本信息，发布者及所有者信息，报告问题或加入讨论的位置等信息等。
- 安全信息：如何安全的应用解决方案信息。
- 应用领域背景信息。
- UML图、BPMN流程图等。
上述内容是实施指南中建议涵盖的内容，并非是强制要求的，选择哪些内容要取决于实施指南所描述的FHIR应用场景以及所要解决的问题。
编写及发布实施指南
创作实施指南的一般工作流程可以分为三个阶段。
在开始阶段，开发者首先需要描述实施指南的应用范围及规范的URL地址（对于HL7指南，规范的URL根目录在 http://hl7.org ；对于其他指南，FHIR官方提供了http://www.fhir.org/guides/registry 的注册发布地址）。开发者需要为实施指南选择一个模板，模板影响了发布后的实施指南的外观、资源在页面中呈现的方式以及用户如何在页面中进行导航。开发者要创建一个不带有任何内容的初始实施指南资源，为实施指南设置版本控制，并通过IG Publisher构建本地实施指南。
在开发内容阶段，开发者需要在实施指南资源中添加用于描述实现的一致性资源、叙述说明及示例、图片等内容，运行本地的实施指南构建来检查所有的内容是否正常。
在发布阶段，通过IG Publisher发布工具将里程碑版本的实施指南转换为一组包含了HTML页面的文件，这些文件可以发布到Web服务器中。
查找及使用实施指南
FHIR官方维护着一个实施指南的注册库，任何公开可用的实施指南都可以注册到这里。
实施指南的主要使用途径是在线阅读。大多数注册的实施指南都提供了下载功能，以便实施者在脱机时可以在本地使用。
工具支持
IG Publisher：FHIR团队提供了一个用于发布FHIR实施指南的工具，该工具接受实施指南（资源，叙述，模板）的输入，并将其转换为一组不同类型的文件。
Simplifier：实现指南编辑器可以让您使用Simplifier中的资源创建实现指南(IGs)。
6.2.4.2 能力声明（CapabilityStatement）
能力声明是 FHIR 中整体一致性框架的关键部分。它用作实际软件功能的陈述，或应用程序提供的一组规则的陈述。例如：哪些资源元素被使用或未被使用的规则，以及添加了哪些不属于FHIR基本规范的扩展元素；支持了哪些RESTful API、消息传递和文档功能等。
能力声明的范围
能力声明（CapabilityStatement）是所有一致性资源的集合，包含了：
- StructureDefinition定义了资源、扩展的使用以及指定元素的值集引用。
- MessageDefinition定义了发送和接收的消息，包括事件的驱动、要交换的内容以及接收时的责任。
- OperationDefinition 定义了除基本规范之中的操作之外的其他操作。
- SearchParameter定义了除基本规范中的搜索功能之外的其他搜索功能。
- CompartmentDefinition 定义了用于访问控制或搜索的资源的逻辑分组。
能力声明的类型
能力声明的使用类型有以下三种：
- Instance：描述一个实例的实现
在这个场景中，能力声明描述了在特定接入点或一组接入点可用的部署和配置的解决方案的能力，该声明准确地描述了如何与部署的解决方案进行接口。
这种类型的声明是期望在调用功能操作时可用的语句类型。它也是构成特定软件安装测试、认证或调试基础的陈述类型。
- Capability：描述软件解决方案的能力
在这个场景中，能力声明描述软件应用程序或组件解决方案的通用功能。因为它不依赖于任何特定的实现，所以概要文件不能提供特定的细节，比如端点地址。
这种类型的声明可以被软件和系统开发人员用作工具以正式描述他们的能力。它还可以作为独立于特定安装的软件解决方案一致性测试的基础。
- Requirements：描述期望的解决方案
在这个场景中，能力声明描述了所需系统的功能。它可以作为体系结构设计过程的一部分来记录所需的系统功能。